A typical device driver is a computer program that enables computer hardware or a computer application to use or communicate with a particular device (e.g., a printer or monitor). Some specialized computer systems use device drivers to perform specialized operations. For example, in a network, a data communications device may use communications port device drivers to receive and send data (e.g., packets, cells, etc.) using input and output ports.
In general, a traditional device driver is monolithic in structure. That is, the device driver typically comprises a single series of instructions which the processor executes as a single process in order to communicate with a particular device. As the processor executes through this series of instructions, the processor serially performs a mixture of primary operations and administrative operations. For example, in a data communications device, a primary operation for a communications port device driver may be to receive data from an input port and/or to send data on an output port. Some administrative operations of the communications port device driver may be to check for requests, and to respond to such requests by (i) setting up or destroying connections, (ii) gathering statistical information, (iii) changing the manner in which resources are allocated for data transfer, and/or (iv) configuring the device port (an input or output port). Generally, the code for such administrative operations is interleaved with code for the primary operations.
In one arrangement, the processor continuously cycles through the series of instructions by jumping back (or looping back) to the beginning of the series once the end of the series is reached in order to re-perform the primary and administrative operations on a continuous basis. In another arrangement, the device driver executes through the series of instructions a fixed number of times (e.g., once) in response to a triggering event such as a wakeup notification or an interrupt from the operating system, and then suspends execution until awaken by another event.
It is common for device driver developers to further develop and improve their device drivers over time. Subsequent device driver versions typically include bug fixes (i.e., solutions to device driver defects), optimizations, and/or new features. For example, when a new version of a device is introduced to the market, the new version typically includes a new device driver designed and developed to take advantage of any new improvements or enhancements in the new version of the device.
Prior to releasing a device driver for normal use, device driver developers typically test their device drivers to identify and correct any defects (or bugs). A newly discovered defect may not have existed in earlier versions of the device driver, or may have existed but not posed a problem in the earlier versions.
The inventors of the present invention have observed that, in certain device drivers (e.g., communication port device drivers for data communications devices), bugs rarely occur in the portions of the device driver that direct the processor to perform the device driver""s primary operations (e.g., receiving data from an input port or sending data to an output port). Rather, the inventors have observed that, in these particular device drivers, bugs are more likely to occur in the portions related to administrative operations (e.g., setting up or tearing-down connections, gathering statistics, and changing resource allocation parameters).
One explanation for this tendency may be that the portions of these device drivers that perform the rudimentary or primary operations are generally not susceptible to new defects. This may be because the code for the primary operations is typically mature (e.g., well developed), fairly simple, and/or short. As such, any bugs that may have existed in the past probably have long been fixed. Furthermore, it may be unlikely that future modifications are needed for these portions of code since these portions are often heavily scrutinized and tested early on in the life cycle of the device driver. Accordingly, if problems are to arise, it is likely that such problems will exist in the portions of code dealing with the administrative operations of the device drivers.
Unfortunately, when a device driver is monolithically structured as a single series of instructions for performing both primary and administrative operations (as is generally the case in a conventional device driver), and when the device driver operates as a single process, bugs in portions of code that deal with administrative operations may affect the portions of code that handle the primary operations. In particular, improper processing of a code portion for an administrative operation may lead to improper processing of a code portion for a primary operation. For example, in a conventional device driver for a data communications device, conventional driver code for a statistics gathering operation (i.e., an administrative operation of the port driver) may include a defective branch operation and interfere with conventional driver code for accessing buffered data received on an input port or destined for an output port (i.e., a primary operation). Although the conventional driver code for accessing the buffered data may have been flawless, the accessing operation can fail due to improper operations of the conventional statistics gathering driver code.
Similarly, an improper memory access by the conventional statistics gathering driver code may lead to improper operation of the conventional driver code for accessing the buffered data. For example, the conventional statistics gathering code may inadvertently overwrite a critical memory location (e.g., a particular control register) used by the conventional accessing code (i.e., the primary operation driver code for accessing the buffered data) rather than read from that location. Such an improper memory access by the conventional statistics gathering code (code for an administrative operation) may cause improper operation of the conventional accessing code (code for the primary operation).
In contrast to conventional device drivers that have code for primary and administrative operations integrated into a monolithic structure that operates as a single serial process, the invention is directed to techniques for sending and receiving data using a device driver that is arranged to prevent improper operation of a non-primary routine (e.g., an administrative operation) from causing improper operation of a primary routine (e.g., a data transfer operation). Such an arrangement enables the primary routine to continue to operate properly after a failure or improper operation of the non-primary routine.
One embodiment of the invention is directed to a data communications device for transferring data. The data communications device includes a port that couples to a network, and a processor coupled to the port. The data communications device further includes memory, coupled to the processor, that stores a device driver. The device driver has a first set of instructions that directs the processor to perform a data transfer routine that moves data between the port and the memory, and a second set of instructions that directs the processor to perform an administrative routine. The first and second sets of instructions are arranged to prevent improper operation of the administrative routine from causing improper operation of the data transfer routine.
Preferably, the administrative routine of the device driver includes at least one of the following routines: a state change routine to cause a state change in the device driver when the device driver operates in the data communications device, a control routine to cause a control change in the device driver when the device driver operates in the data communications device (e.g., storing a hardware address to perform MAC address filtering), a resource management routine to manage a device driver resource, a statistic collection routine that collects statistical information describing an operation of the data transfer routine, a network management routine that collects network management information describing operation of the device driver (e.g., port name information for determining relationships, and for locating and identifying external nodes), and/or a housekeeping routine that performs initialization and cleanup operations for the device driver. The administrative routine may include only one of the above-listed routines or any combination thereof.
In one arrangement, the data transfer routine has access to a restricted area of the memory, and the administrative routine does not have access to the restricted area. Rather, the administrative routine has access only to an administrative area which excludes the restricted area of the memory to prevent a memory access operation of the administrative routine from causing improper operation of the data transfer routine. Accordingly, if the administrative routine includes a programming bug causing improper operation of the administrative routine, the administrative routine will not corrupt the restricted area of the memory, and the data transfer routine can continue to operate normally.
In another arrangement, the first set of instructions is non-integrated with the second set of instructions (e.g., the second set of instructions executes as one or more separate processes). Accordingly, the device driver is non-monolithic in structure, and more particularly, separated in a manner that prevents improper processing of the second set of instructions from causing improper operation of the data transfer routine. Accordingly, improper execution of the second set of instructions (i.e., the administrative routine code) will not inadvertently cause improper execution of the first set of instructions (i.e., the data transfer routine code).
In yet another arrangement, the administrative routine includes a state storage routine that stores, in the memory, operating state information of the data transfer routine, and a backup routine that transfers data (e.g., uses the-port to receive or send data) using the operating state information, in response to a failure of the data transfer routine to transfer data using the port. Preferably, the backup routine remains available in an up and running, idle condition, i.e., a xe2x80x9chot-stand-byxe2x80x9d condition.
In another arrangement, the memory further stores an upgrade application having a replacement set of instructions that is different than the second set of instructions of the device driver, and a control set of instructions that directs the processor to replace the second set of instructions of the device driver with the replacement set of instructions. The replacement set of instructions directs the processor to perform a new administrative routine. Preferably, the control set of instructions of the upgrade application is capable of swapping the second set of instructions with the replacement set of instructions while the processor operates under direction of the first set of instructions, i.e., while the data transfer routine operates. Accordingly, there can be dynamic replacement of the second set of instructions while the device driver is in operation.
Another embodiment of the invention is directed to a computer program product that includes a computer readable medium having instructions stored thereon for transferring data in a network. The instructions, when processed by a data communications device, cause the data communications device to perform the steps of (a) processing a first set of instructions to perform a data transfer routine that moves data between a memory and a port which is coupled to a network, and (b) processing a second set of instructions to perform an administrative routine. The first and second sets of instructions are arranged to prevent improper operation of the administrative routine from causing improper operation of the data transfer routine. Preferably, the data transfer routine has access to a restricted area of the memory, and the administrative routine does not in order to prevent a memory access operation of the administrative routine from causing improper operation of the data transfer routine.
Another embodiment of the invention is directed to a technique for operating a device, which involves loading, on a computer system, a device driver having a first set of instructions and a second set of instructions, processing the first set of instructions to perform a primary routine that operates the device, and processing the second set of instructions to perform an administrative routine. The first and second sets of instructions are arranged to prevent improper operation of the administrative routine from causing improper operation of the primary routine. In this embodiment, the primary routine may have access to a restricted area of the memory, while the administrative routine does not have such access to prevent a memory access operation of the administrative routine from causing improper operation of the primary routine. Preferably, a processor of the computer system executes the first set of instructions as a first process and the second set of instructions as a second process.
The first and second processes preferably communicate with each other using an interprocess communications mechanism. In one arrangement, the first and second processes communicate by exchanging data in a shared area of the memory. In another arrangement, the first and second processes communicate by passing messages to each other. In yet another arrangement, the first and second processes communicate using events and semaphores.
Another embodiment of the invention is directed to a technique for transferring data which involves processing a first set of instructions to perform a data transfer routine that moves data between memory and a port which couples to a network, and processing a second set of instructions to perform an administrative routine. The first and second sets of instructions are arranged to prevent improper operation of the data transfer routine from causing improper operation of the administrative routine, and to prevent improper operation of the administrative routine from causing improper operation of the data transfer routine. Preferably, the administrative routine includes a configuration routine that verifies and configures the port for data transfer. Furthermore, the administrative routine preferably includes a control routine that handles network control events.
The above-described features of the invention may be employed in data communications devices and other computerized devices such as those manufactured by Cisco Systems, Inc. of San Jose, Calif.